Computer systems can include data objects that correspond to products, technical assets, contacts, partners or other tangibles. Such objects may be assigned to one or more categories in the computer system to indicate properties of the data object. For example, a data object that corresponds to a vehicle may be assigned to a category “trucks”. Categories may be arranged in hierarchies; for example, the category “trucks” may have a subcategory, or specialization, that is called “light trucks”.
Objects may be transferred from one computer system to another. For example, an object that is created in one system may be temporarily transferred to a second system for a specific purpose. The transfer may correspond to a physical relocation of the tangible item to which the object corresponds. For example, when a technical asset is brought from one country to the next, the object may be distributed to a computer system that is associated with, and optionally located in, the new country. The object may be updated while in the new system, for example if work is being done on the technical asset, and the updated object may thereafter be passed back to the first system.
The handling of the object in a computer system may be affected by the system architecture. Moreover, the two (or more) computer systems that handle the object may have different architectures. Particularly, the systems may have different categories or category hierarchies to which objects in the respective systems should be assigned. For example, the system that sends the data object may have N number of categories, including a category “cars” with specializations for different car brands. The recipient system, in turn, may have M number of categories, including a category “vehicles” (covering not only cars) with specializations for two-wheel and four-wheel driven vehicles.
The difference in categories can present challenges when distributing an object between the systems. For example, all cars are vehicles but not every vehicle is a car. This means that every object assigned to a vehicles category cannot be automatically assigned to a cars category because some of the vehicle category objects may not be cars. Accordingly, it may not generally be possible to perform a one-to-one (or 1×1) mapping between categorizations in these systems, because this would assume that the category hierarchies are the same and have the same meaning. Rather, it may be necessary to perform a N×M mapping.
Building a N×M mapping is time consuming and may lead to inconsistencies. Particularly, there may be a lack of convergence in the mapping. That is, if a category in the sender system is mapped to a category in the recipient system and, upon inverting the mapping back to the sender system again, the inverse mapping does not target the specific sender category but rather another category, the mapping may lack convergence.
Existing systems also have used 1×N directed key mappings that involve using a mapping profile that provides a process for mapping authorizations. The mapping process includes criteria for matching data objects to each other for the mapping. For example, such mappings are implemented in the Master Data Management 2.0 product available from SAP AG in Walldorf (Baden), Germany. One disadvantage with this solution is that it does not provide an automatic categorization during a distribution process without user interaction.